如同前幾天說的，其實 DevOps 源自於跨團隊之間的溝通不良，其實我覺得還有另一個衍伸議題是「因為太少溝通而減少腦力激盪的機會」。當團隊把角色區分後，職能切清楚後，除了會因為立場不同而造成溝通不良以外，也會因為大家認為各自的權責範圍就是到這，而不會再去多想一點。

以我們團隊來說，我們使用的開發模式是 Scrum ，所以我們會有 PO 與開發團隊，我們接到使用者的需求，希望現在監控線路的頁面可以更細一些，目前我們只有做主線路的監控，使用者希望可以連細項的線路也能有監控。如果把職能分細，會認為 PO 要負責把功能規劃好，然後再交給開發團隊實作。

這樣乍看下沒什麼問題，各司其職，但我認為這樣少了很多腦力激盪的機會，以這次的例子來說，PO 一開始的想法是透過製作另一個相似的頁面，只是把細項展開，透過兩個頁面來滿足使用者需求，但問題來了，這個頁面是會需要告警的，目前使用者正在使用中的告警頁面已經太多，類似的功能還要開兩個頁面，實在有點浪費。

我：「以我對使用者的了解，他們應該不會想要開兩個頁面，太麻煩了，要不要把現在的頁面資料改成主線路＋子線路的總和，當告警時，使用者點擊後再跳轉至細項頁面」
前端工程師：『還是說我做的 hover 功能，滑鼠移上去就可以看到細節，hover 不會很難』
PO：我最喜歡聽到工程師說不難了(眼睛發亮)
我：「但我覺得 hover 對我們的使用者來說好像不太方便（不敢肯定）」
前端工程師：『還是說我們做當點擊後直接在旁邊或下面展開？』
PO：好像還不錯...

後面還有一些討論，就不贅述，重要的是我、PO、前端工程師都根據我們不同的經驗，提出我們覺得可行的做法，最終挑出幾個再讓使用者挑選，這樣的方式會比只有讓 PO 一個人設計來得更佳多元，有時 PO 體諒工程師的辛苦，也會希望能夠盡量減少工程師的工作，但畢竟專業領域不同，有時不見得可以想到最佳解，反而會好心卻辦了壞事。